Related Issues

Fixes #12145

Proposed Changes

Resuming a pipeline from a pipeline_snapshot failed with PipelineComponentsBlockedError when the breakpoint had been hit on the second (or later) visit of a component inside a loop. First-visit resume worked; later-visit resume did not.

Root cause. When a snapshot is created, the paused component's inputs are stored and later restored through _convert_to_internal_format, which marks every restored input with sender = None — i.e. they look like user inputs. In has_any_trigger, a user input can only trigger a component on its first visit (component["visits"] == 0). On a loop re-visit the restored component_visits for that component is already >= 1, so:

• trigger_from_predecessor is False (sender is None),
• trigger_from_user is False (gated on visits == 0),
• trigger_without_inputs is False (the component has senders),

so the component the run is supposed to resume at is marked BLOCKED and never selected, and the pipeline reports itself blocked.

Fix. The run already knows which component it is resuming at (pipeline_snapshot.break_point.component_name). When filling the initial priority queue, that component is now flagged as a resume target so it can trigger exactly once regardless of its visit count. The flag is only set during the initial fill on the resume path; every other queue fill (normal runs, the async path, and mid-loop refills) is unchanged, so a resumed component continues to be driven by predecessor triggers on subsequent iterations.

Changes:

• has_any_trigger gains a trigger_from_resume condition (active only when the component carries the is_resume marker and has restored inputs).
• _fill_queue accepts an optional resume_component_name and tags that one component.
• Pipeline.run passes the resume component name into the initial _fill_queue call.

How did you test it?

• Added a regression test (test_resume_snapshot_taken_on_a_later_loop_visit) reproducing the issue exactly (breakpoint on visit_count=1 inside a BranchJoiner loop), asserting the resume no longer raises and finishes the loop.
• Verified manually that a normal (no-breakpoint) run, first-visit resume (visit_count=0), and pausing/resuming a non-greedy component on a later visit all behave correctly.
• The existing test/core/pipeline/test_component_checks.py suite (74 tests) still passes.

Notes

Scope is limited to the reported PipelineComponentsBlockedError. An orthogonal, pre-existing snapshot-resume limitation involving greedy joiners over multiple loop hops (reproducible on main without this change) is intentionally left out of scope.

This PR was written with AI assistance (Claude Code) and reviewed by me before submission.

🤖 Generated with Claude Code